最近的一些感想

最近遇到几个案例，对一些以前感觉没啥问题的事情产生了一些新的想法。这周就要过年了，因此今天可能是春节前最后一篇讨论技术的文章。在春节期间，争取抽空写一些吃喝玩乐的文章。

前阵子一个客户的一个关键系统出了一次大故障，这套系统是6年前从IOE架构迁移到云平台上的，整个云平台建设了7年多了，而系统上线也有6年多了，在此期间，云平台很好地支撑了系统的运行，没有出过什么比较大的故障。前阵子突然应用不可达，现场监控人员检查发现有几十台服务器的心跳失踪，云服务本身也出现了严重故障。最后对这几十台服务器做了强制性重启后，系统恢复正常了。因为故障发生时有些服务器已经无法在云平台上管理，因此必须通过BMC强制重启，整个过程持续了数个小时。这也导致了这套关键系统的大部分服务出现了2小时以上的断服。

当这套系统在IOE架构上运行的时候，故障率肯定比上云后要高，基本上每年都会出一些故障。不过数据库有RAC和ADG备库，应用服务器有WLS集群，因此大部分故障都不会完全中断业务，顶多是部分业务短暂出现几分钟到几十分钟的故障。系统上云后，确实这种级别的故障少了很多，哪怕出现一些问题，大部分也可以在更短的时间内恢复了。出现如此大的故障，这6年里也只有这么一次。

似乎上云后，系统更稳定了，但是这一次故障不免让人反思。对于特别关键性的系统，一旦出问题将会引发社会性的问题。对于这样的系统，这种用复杂性带来的整体可用性的提升是不是真的是一种比较好的选择。在上云之前，这套系统就是两台IBM小型机+一台集中式存储作为主系统，另外一台档次略低的小型机加一台档次略低的集中式存储作为备系统，运行Oracle RAC+ADG，应用服务器则是部署在几台物理机上的一个WLS集群，每台物理机上跑几个WEBLOGIC实例。在IOE架构下，小故障WLS集群和RAC就搞定了，大故障ADG可以承担。因此只要对外服务的网络没有问题，不会出特别大的故障，哪怕有故障也有把握在30分钟内完成切换接管。    

上云后就复杂了，这套系统部署在一个200多个节点的小型私有云环境中，和其他十几套小系统共用一套云基础设施。这几年业务部门也提出过做容灾的想法，不过因为涉及到要在异地机房建设一套类似规模的云，投资比较大，再加上这些年整个云平台表现不错，这个建容灾的方案就被淡忘了。大家似乎忘了一件事，那就是云平台再稳定，也不能达到100%的可靠性，而一旦复杂的底层IT基础设施出现问题，那么想要恢复运行并非易事。

按理说云平台上的很多单点故障都是能够通过自动切换来快速恢复的，但是这回出问题的却是云平台核心本身，这导致了当时出问题的节点上的ECS虚拟机并没有发生预期的自动切换，而是处于HANG死状态。出现这种故障的概率极低，但是并非不会发生。就像我们虽然没有活100岁，但是这几十年里已经经历过了很多次百年难遇的自然灾害了一样，一旦问题爆发，就是百分之百的厄运。我们是否应该重新思考一下，对于这种十分关键并且不具有互联网式的动态负载的系统，用较为简单的传统的架构是否更为合理一些呢？

说到互联网思维深深影响了传统企业的IT这个话题，想起了最近和一个朋友交流的时候谈到对于系统故障的预警与处置的问题。他们觉得现在系统都做了互联网化的改造，当系统故障发生时，采用预设的故障处置方案自动切就可以了。传统的故障处置流程在当前他们的IT环境中已经不适用了。在我的观念中，无论IT基础架构与基础设施如何变化，故障的事前预警，事中处置，事后分析依然是不能省略的。事前预警可以防微杜渐，事中决策和处置可以实现最小代价的故障恢复，而事后分析更是避免错误再次发生所必须要做的事情。不过我的这个观点在一些人眼中已经是过时的东西了。只要系统能够确保正常运行，这些费力不讨好的事情不是必须做的，优秀的IT基础设施能解决系统中的这些复杂问题。这些观点我似乎还一时接受不了。

如果每次故障发生都是通过平台的容错机制去自动解决的，我们无需关注，那么可能会忽略一些十分重要的隐患，一旦平台无法自己解决的问题出现的时候，那就会产生灾难性的后果的。实际上我今天所说的案例就是如此。很可能在大故障发生前，一些小的故障已经发生了，只是这些问题被云平台自身的容错能力解决掉了，因此并没有引起我们的关注。而当遇到了我们必须关注的故障的时候，云平台已经无力自行解决，这种问题大多数也超出了运维人员的技术能力，这样灾难就不可避免地发生了。    

互联网企业的一些先进的思路与技术促进了传统行业IT技术的发展，但是运维的一些本质性的东西依然没有改变。云平台不需要容灾，分布式数据库不需要备份等等被某些人忽悠的概念，是不是要认真思考一下呢？恐怕这些问题搞技术的人都有比较靠谱的认知，麻烦的是，这些话现在我们的领导们都信了。